The present invention relates to systems used in the utility industry. In particular, the invention relates to metering, network, database, and computer application systems used in the utility (i.e., gas, water, and electricity) industries.
Heretofore, it was common for the manufacturer of meters or other devices used in the utility industry to develop metering devices which could be read by certain, specific means, and which could be programmed, if at all, by certain specific means. By way of example, in the electricity industry, the manufacturer of a particular meter could include a register thereon which was capable of storing certain metering information, i.e., total KwHr metered, time of use information, maximum demand over some time period, etc. For each meter developed by each manufacturer, the way in which the data was retained in the meter and the manner in which data could be extracted from the meter was often unique to a particular meter. Thus, it was not only possible, but common, for there to be a variety of meters, manufactured by the same manufacturer which each retained somewhat different data in somewhat different formats, and it was common to have situations in which it was necessary to extract that data using a specific technique, which involved the use of a unique piece of software. By way of example, meters could be read using optical ports, direct (wired) connections, telephone modems, power line carrier (xe2x80x9cPLCxe2x80x9d) communications, radio (xe2x80x9cRFxe2x80x9d) means, etc. Further, each meter would typically use a different type of software to read and/or program features which were present in the meter. If that did not complicate matters enough, each manufacturer would typically develop its own communications xe2x80x9cprotocolxe2x80x9d to communicate with the meters which it developed.
In the area of communications protocols alone, different meter manufacturers each approached the idea of a protocol somewhat differently. Thus, one manufacturer might define a communications protocol in a manner which allowed a particular command to extract a particular type of data from a particular meter. Yet another manufacturer might define the xe2x80x9cprotocolxe2x80x9d as the communications method for communicating with the meter, and the meters of that manufacturer would typically retain data in each of its meters in particular memory locations. In order to program (or obtain data from) the latter type of meters, it was necessary to know both the protocol and the xe2x80x9cmemory mapxe2x80x9d which detailed the memory locations of the data within the meter.
In view of the numerous types of meters and the numerous meter manufacturers, the number of individual pieces of computer software which were needed by a utility to set up, program, and read meters continued to grow, much to the dismay of the utilities which found that they needed to maintain numerous pieces of computer software in order to accomplish the tasks which they had to regularly perform. Further, depending upon the size of the utility, the purpose of the software, and when the software was initially installed, utilities could find themselves operating software on a number of different platforms, which typically included UNIX(copyright), MS-DOS, and WINDOWS.
In an effort to assist the utilities in limiting the number of different computer software packages which they had to maintain, suppliers to the industry started to provide so-called xe2x80x9cmulti-vendorxe2x80x9d systems. Such multi-vendor systems, i.e., the Schlumberger Industries MULTI-MASTER(copyright) software or the Utility Translation System MV-90(trademark) software, were able to communicate with the meters of more than one manufacturer. However, they, too, had problems, in that a number of manufacturers perceived the need to maintain their protocols and memory maps as trade secrets in order to prevent competitors from xe2x80x9ccloningxe2x80x9d their equipment and thereby trading upon the good will which they had established with their customers. This was a particularly troublesome problem in those instances in which an interloper appeared on the scene with a meter which they claimed to be a xe2x80x9cclonexe2x80x9d of a meter sold by an established manufacturer, and then only after buying the meter, would the utility learn that the xe2x80x9cnewxe2x80x9d meter did not perform the same as the one which had been xe2x80x9cclonedxe2x80x9d.
Other problems with multi-vendor systems involved the fact that in order to develop such systems it was necessary for the system developer to have access to information which the meter manufacturer might consider to be proprietary. Accordingly, the development and marketing of a new meter often became difficult. It was difficult for the meter manufacturer, which had to have software support for its meter, because until the company doing the software support actually implemented the meter support in their software, and until the software was released, the utilities could not use the meter, so the manufacturer could not sell the meter. The meter manufacturers could not add the software support for new meters into existing multi-vendor systems due to the closed architecture which such systems employed. Similarly, the software support companies were continuously in a situation in which they were trying to implement support for new meters, while performing updates to their packages to further support meters already in the field.
From the utilities perspective, unless a meter had adequate system support, it could not be used. Even meters which were supported, could not always be used, if the system on which they were supported differed from the system which the particular utility was using. Thus, depending upon the computer platform which was used at a particular utility, the operating system being used on that platform, whether or not the utility had made a committment to the use of a particular multi-vendor computer software system, and the types of meters already in the utility, the utility""s decision to purchase a particular meter could be greatly affected.
Finally, individual utilities would often find the need to have specialized computer application software developed to meet specific, internal needs of the utility. As there are many utilities which do not maintain their own internal programming staff, it was necessary for them to hire outside consultants to develop the applications software. For both those utilities which had an internal programming staff and those who used outside programmers it was necessary to obtain the communications protocol, and memory map information from the meter manufacturers to even begin to develop an application which could be used to generate even a simple report.
Thus, unless a utility chose to limit the number of types of meters which it would purchase, the types of computers on which it would operate its software, the particular databases which it maintained, and a host of other factors, all of which were limiting to the manufacturer""s ability to meet specific needs, there was no easy way to address the issues of universal system compatibility. Even worse, each time another new type of meter or application or database engine or computer system was introduced, the problem of integrating the various items into an existing system grew exponentially.
In view of the foregoing problems, many utilities called for the manufacturers to develop a xe2x80x9cstandardxe2x80x9d way of communicating with metering equipment. However, other manufacturers and utilities wanted to retain the ability to add additional features to the future metering equipment which they sought to manufacture and purchase. Consequently, there was no simple solution which was universally acceptable, and as new microprocessor based solid-state meters brought additional features to the market place, and as demand developed for automatic meter reading (xe2x80x9cAMRxe2x80x9d) equipment increased, the problems continued to mount.
In particular, utilities have turned to AMR systems in order to allow timely reads of customer""s meters on a scheduled and/or demand basis, without requiring access to the customer premises. These systems are becoming increasingly complex as new features are added such as outage detection, tamper detection, remote disconnect, and other distribution automation and demand side management (xe2x80x9cDA/DSMxe2x80x9d) applications.
The continued demand for new features requires extension of the master station software in several areas. First, there are new applications needed for handling these new functions. Second, there is pressure to support a large number of different metering devices, i.e., electric, water, gas, and heat metering devices. Third, it is necessary to support different communication infrastructures, since different communications methods such as telephone inbound and outbound, radio networks, power line carrier, hand-held devices, and drive-by devices are needed in different situations. Finally, t is desirable to support a variety of different databases, since various utilities have standardized on different database packages.
Conventional AMR and DA/DSM systems typically suffer from a lack of extensibility due to the monolithic nature of the master station software. As described above, adding any new features to such systems is a very difficult process, and requires recompilation and/or relinking of the software to accommodate the new features. Typically, these extensions can only be performed by developers having access to the source code of the particular system.
In view of the foregoing problems, a new approach was required.
In contrast to the monolithic structures of the prior art, the present invention is comprised of relatively small modules which export well-defined application interfaces using a component object model (xe2x80x9cCOMxe2x80x9d). It is based on the industry standards of Object Linking and Embedding (xe2x80x9cOLExe2x80x9d) and Open Database Connectivity (xe2x80x9cODBCxe2x80x9d). The present system allows straightforward extensions in any of the four dimensions listed above (applications, communications, metering devices, and databases) without requiring recompilation or reliking of the system, and provides compatibility with many commercial software packages.
A key foundational decision in the implementation of the preferred embodiment of the invention was the selection of the software framework, i.e., the collection of underlying software technologies used to construct the software architecture. Technology choices had to be made in the areas of the component object model, component communication, database connectivity, the underlying application programming interface, the class library, and operating systems.
To select this framework, the primary goals of the inventive system were to maximize the effectiveness of software development, i.e., get the best product for the development money spent; and to provide an open system which permits easy extension by the customer and/or third party developers and which can integrate with commercial software packages.
Based upon these primary goals, a set of selection criteria for the framework was defined. It must be based upon well-supported commercial standards. It must permit decomposition into small modules which are easier to develop and customize. It must permit easy customization via new modules without relinking the entire system. It must permit maximum use of commercial components within the framework. It must have the ability to target all required platforms using the same source code. It must have a predicted longevity. It must provide support for the most widely used databases. It must support distributed computation for upward scaleability. Finally, it should be in the mainstream of software development to maximize the options for software tools, applications, and cross-platform support.
Based upon the foregoing framework requirements, a completely new object oriented, modular approach to system support for use in the utility industry was developed, and that is the subject of the present invention. In accordance with the invention, it was determined that the techniquies of Object Linking and Embedding (xe2x80x9cOLExe2x80x9d), as described by Brockschmidt, Kraig; in Inside OLE 2, Microsoft Press (1994), the contents of which are incorporated herein by reference, provided the leading standard for object-based component communication. Over 1,000 commercial applications provide OLE support, which allows them to be integrated with the inventive system. OLE supports decomposition into small modules, and allows customization by adding or replacing modules without recompiling or relining the system.
OLE objects can communicate through three different mechanisms. In particular, objects may be called by direct function calls for those objects that are linked through a dynamically linked library (xe2x80x9cDLLxe2x80x9d). This provides the best performance, but requires the DLL to be linked to the same executable file (xe2x80x9cEXExe2x80x9d file). Objects can also be accessed in different executable files in the same computer through a local remote procedure call (xe2x80x9cRPCxe2x80x9d) as described by Guy Eddon in RPC for NT, RandD Publications (1994), the contents of which are incorporated herein by reference. This allows adding new modules or replacing modules without linking, but has lower performance than that provided by a DLL. Finally, objects can be accessed on other machines through Distributed Computing Environment (xe2x80x9cDCExe2x80x9d) RPCs. This allows a fully distributed system to be deployed for upward scaleability. An extremely attractive aspect of the present inventive approach is that the client does not have to know in advance which of the three cases described above apply. The client simply sends messages to the object, and the system determines how to get the message to the object. Thus, the same code can be used regardless of whether the DLL is linked directly or whether it is distributed on a different computer.
In an alternative embodiment of the present invention, component communication could be carried out using Common Object Request Broker Architecture (xe2x80x9cCORBAxe2x80x9d). Although this is also a strong technology, and could be used without departing from the inventive concept, it is not as widely used as that described above, and relatively few commercial applications are available that support CORBA. Commercial support for OLE is clearly growing, while the future of CORBA is less certain. However, those skilled in the art will recognize that there are a number of alternatives to the preferred embodiment of the invention, and that if interoperability with CORBA is needed, it is available, and it is within the scope of the present invention. In fact, Digital Equipment Corporation, located in Maynard, Massachusetts, provides a gateway between CORBA and OLE which is called their Object Broker package. Accordingly, while CORBA is considered an alternative, it is by no means inconsistent with the teachings herein.
The underlying component object technology used by OLE is the Component Object Model (xe2x80x9cCOMxe2x80x9d), the selection of OLE, therefore, constrains us to also use COM which provides a standard for component interoperability. This implies that all COM components will work together, regardless of their source (in-house, commercial, third party, etc.), when the components are developed (components developed now will work with components developed years ago, and they will continue to work with components developed in the future), and what programming language is used (C, C++, Basic, etc.). Furthermore, such objects can be used in a distributed or client/server architecture without any change, as discussed above. This interoperability is achieved through the underlying technologies of queryable interfaces and unique identifiers.
Queryable interfaces allow a client to ask what interfaces are supported. This allows object and client to communicate in the richest set of languages which they share in common. It also allows discovery of features at run-time instead of hard-coding at compile time, and permits new functionality to be added later with full backwards compatibility.
The provision of unique identifiers is actually part of the Distributed Computing Environment (xe2x80x9cDCExe2x80x9d) standard. This provides each object with a globally unique identifier so that the object may be located, even if it is located on a remote machine. This is key for supporting a distributed architecture.
The RPC mechanism used with OLE is DCE/RPC. As will be recognized by those skilled in the art, while local RPC is presently a part of the OLE standard, DCE/RPC is not part of that standard. However, DCE/RPC is a widely supported standard that provides excellent features for distributed systems such as unique identifiers, support for heterogeneous networks, and security.
In the preferred embodiment of the invention, the WIN32 Application Programming Interface (API) was selected. While the selection of the underlying API is extremely important, and while potential candidates included the WIN16, WIN32, and UNIX(copyright) APIs, the WIN32 API was the preferred selection, although any of the others could be used without departing from the inventive concept. The WIN16 API was rejected because of the longevity constraint, since all new Microsoft support is for WIN32 API only. It first seemed that both the WIN32 and UNIX(copyright) APIs would have to be supported, since products must be deployed on both Windows NT(trademark) and UNIX(copyright) platforms. However, this violated the criteria to target all required platforms using the same source code.
The solution to this dilemma was to use third party software packages that support the WIN32 API on UNIX(copyright) platforms as described by Cullens, Chane and Blackwell, Ken in Cross-Platform Development Using Visual C++, MandT (1995), the contents of which are incorporated herein by reference. This allows development using the WIN32 API and then retargeting the software to UNIX(copyright) by linking with third party packages that resolve all of the WIN32 API references in terms of the underlying UNIX(copyright) API, as illustrated by FIG. 2. Retargeting packages are provided by several different vendors. These products have the additional advantage that the differences between various UNIX(copyright) platforms (SUN OS 4.1.3, Solaris 2.x, HP/UX, AIX et cetera) are handled by providing different libraries, so that code can be common even between different UNIX(copyright) platforms.